Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.

3 года назад мы писали об утилите ESXi5 Community Packaging Tools 2.0, которая позволяет создавать собственные пакеты для VMware ESXi в форматах VIB (VMware Installation Bundle) and ZIP (VMware Offline Bundle). В результате VIB-файлы получают уровень доверия (acceptance level) Community Supported. Зачастую, эти утилиты необходимы пользователям для включения сторонних драйверов устройств в состав дистрибутива платформы ESXi, которые отсутствуют в стандартном комплекте поставки.

На днях автор проекта (и он же блоггер на v-front.de) выпустил обновление этого средства - ESXi Community Packaging Tools 2.3.

На самом деле, изменений было сделано не так много, но они есть и важные:

• Появилась полная поддержка VMware vSphere 6 (именно поэтому "ESXi5 Community Packaging Tools" (ESXi5-CPT) переименованы в "ESXi Community Packaging Tools" (ESXi-CPT).
• Пакетный сценарий TGZ2VIB5.cmd обновлен до версии 2.3.
  • Пофикшено название уровня доверия (acceptance level) "certified" (раньше он назывался "vmware").
  • Добавлены пресеты конфигураций "ESXi 6.0+ driver" и "VMware Tools" (tools-light.vib). Теперь вы можете создать свой пакет VMware Tools для распространения в гостевых ОС на базе гипервизора ESXi!
  • Добавлена поддержка типа VIB-пакета (vibType) "locker".
• Пакетный файл VIB2ZIP.cmd обновился до версии 1.3 - туда были добавлен выбор настроек совместимости для VMware ESXi.

Видео о создани VMware Offline Bundle с помощью VIB2ZIP:

Скачать ESXi Community Packaging Tools версии 2.3 можно по этой ссылке.

Многие из вас знают, что в VMware vSphere есть такой режим работы виртуальных дисков, как Raw Device Mapping (RDM), который позволяет напрямую использовать блочное устройство хранения без создания на нем файловой системы VMFS. Тома RDM бывают pRDM (physical) и vRDM (virtual), то есть могут работать в режиме физической и виртуальной совместимости. При работе томов в режиме виртуальной совместимости они очень похожи на VMFS-тома (и используются очень редко), а вот режим физической совместимости имеет некоторые преимущества перед VMFS и довольно часто используется в крупных предприятиях.

Итак, для чего может быть полезен pRDM:

• Администратору требуется использовать специальное ПО от производителя массива, которое работает с LUN напрямую. Например, для создания снапшотов тома, реплики базы данных или ПО, работающее с технологией VSS на уровне тома.
• Старые данные приложений, которые еще не удалось перенести в виртуальные диски VMDK.
• Виртуальная машина нуждается в прямом выполнении команд к тому RDM (например, управляющие SCSI-команды, которые блокируются слоем SCSI в VMkernel).

Перейдем к рассмотрению схемы решения VMware Site Recovery Manager (SRM):

Как вы знаете, продукт VMware SRM может использовать репликацию уровня массива (синхронную) или технологию vSphere Replication (асинхронную). Как мы писали вот тут, если вы используете репликацию уровня массива, то поддерживаются тома pRDM и vRDM, а вот если vSphere Replication, то репликация физических RDM будет невозможна.

Далее мы будем говорить о репликации уровня дискового массива томов pRDM, как о самом часто встречающемся случае.

Если говорить об уровне Storage Replication Adapter (SRA), который предоставляется производителем массива и которым оперирует SRM, то SRA вообще ничего не знает о томах VMFS, то есть о том, какого типа LUN реплицируется, и что на нем находится.

Он оперирует понятием только серийного номера тома, в чем можно убедиться, заглянув в XML-лог SRA:

Тут видно, что после серийного номера есть еще и имя тома - в нашем случае SRMRDM0 и SRMVMFS, а в остальном устройства обрабатываются одинаково.

SRM обрабатывает RDM-диски похожим на VMFS образом. Однако RDM-том не видится в качестве защищаемых хранилищ в консоли SRM, поэтому чтобы добавить такой диск, нужно добавить виртуальную машину, к которой он присоединен, в Protection Group (PG).

Допустим, мы добавили такую машину в PG, а в консоли SRM получили вот такое сообщение:

Device not found: Hard disk 3

Это значит одно из двух:

• Не настроена репликация RDM-тома на резервную площадку.
• Репликация тома настроена, но SRM еще не обнаружил его.

В первом случае вам нужно заняться настройкой репликации на уровне дискового массива и SRA. А во втором случае нужно пойти в настройки SRA->Manage->Array Pairs и нажать там кнопку "Обновить":

Этот том после этого должен появиться в списке реплицируемых устройств:

Далее в настройках защиты ВМ в Protection Group можно увидеть, что данный том видится и защищен:

Добавление RDM-диска к уже защищенной SRM виртуальной машине

Если вы просто подцепите диск такой ВМ, то увидите вот такую ошибку:

There are configuration issues with associated VMs

Потому, что даже если вы настроили репликацию RDM-диска на уровне дискового массива и SRA (как это описано выше), он автоматически не подцепится в настройки - нужно запустить редактирование Protection Group заново, и там уже будет будет виден RDM-том в разделе Datastore groups (если репликация корректно настроена):

Помните также, что SRM автоматически запускает обнаружение новых устройств каждые 24 часа по умолчанию.

Гостевая статья нашего спонсора - компании ИТ-ГРАД, предоставляющей услуги виртуальных машин VMware в аренду. В этой статье речь пойдет о плюсах интеграции среды виртуализации VMware и систем хранения NetApp. В частности, продолжим разбираться с VAAI и посмотрим, как использование такой связки может помочь в проектах по разработке ПО.

Некоторое время назад мы писали о решении VMware vRealize Automation, которое появилось в результате ребрендинга продукта vCloud Automation, который предназначен для автоматизации операций в облачной инфраструктуре (в том числе гетерогенной и гибридной) на базе различных гипервизоров (не только VMware vSphere) .

Анонс новой версии VMware vRealize Automation 7 был сделан еще на VMworld Europe 2015, но так как обновление до сих пор не вышло, то еще не поздно рассказать вам о его новых возможностях.

Итак, давайте взглянем на новые возможности платформы VMware vRealize Automation 7:

1. Упрощенная процедура развертывания.

vRealize Automation 7 теперь не требует сложных операций при установке и настройке - развертывание решения происходит в едином интерфейсе с предлагаемыми настройками (также есть настройки аутентификации и Single Sign-On), которые потом можно просто изменить. Консоль выглядит намного приятнее (кликабельно):

2. Унифицированный дизайн инфраструктуры сервисов.

Теперь в наглядном проектировщике инфраструктуры сервисов все делается, в основном, с помощью мыши, поэтому построить архитектуру ИТ-инфраструктуры вашего предприятия стало значительно проще:

3. Поддержка VMware NSX для сетевой топологии и инфраструктуры безопасности.

Теперь компоненты сетевой инфраструктуры VMware NSX доступны для построения сетевой архитектуры и инфраструктуры безопасности. Их можно переносить в визуальном редакторе с помощью Drag&Drop:

Это отменяет необходимость проектировать виртуализованную сетевую инфраструктуру за пределами vRealize Automation.

4. Формализованные описания сервисов и шаблоны.

Теперь шаблоны описания сервисов можно редактировать как текстовые файлы. Это позволяет более гибко подходить к проектированию и унификации архитектуры DevOps. Также поддерживаются системы управления версиями для хранения объектов - скриптов, шаблонов и сценариев рабочих процессов, файлов описания сервисов и т.п.

5. Улучшенная расширяемость решения для интеграции со сторонними облачными решениями.

Теперь vRealize Automation 7 имеет более широкие возможности по вызову операций в сторонних решениях для управления виртуальными инфраструктурами. Теперь появился Event Broker, который стандартизирует операции по передаче команд сторонним средствам.

Кроме того, был существенно доработан API и улучшена интеграция с облачной инфраструктурой Amazon AWS и VMware vCloud Air, что позволяет строить гибридные облака для предприятия (частное+публичное):

На момент написания заметки VMware vRealize Automation 7 еще не доступен для скачивания (обещают до конца 2015 года), но подписаться на оповещение о его доступности можно по этой ссылке.

Как некоторые из вас знают, сейчас в разработке у VMware находится новая версия продукта Virtual SAN (о текущей версии VSAN 6.1 мы писали вот тут), а скоро появится ее бета. Дункан написал пару интересных постов о том, какие возможности для экономии дискового пространства появятся в новой версии Virtual SAN.

А именно:

• erasure coding
• deduplication
• compression

Обещают, что эти 3 вещи уменьшат потребляемое дисковое пространство в разы. Давайте посмотрим на некоторые детали этих возможностей.

Erasure coding (коррекция ошибок - "RAID из узлов")

Сейчас если вы используете параметр failures to tolerate =1 (зеркальная избыточность), то вам нужна двойная емкость в кластере. То есть, если будет 100 ГБ под виртуальные машины, то на хостах суммарная емкость должна составлять 200 ГБ.

По аналогии с RAID5/6 и другими типами RAID с чередованием, пространство хранения Virtual SAN будет представлять собой "RAID из хостов ESXi". Таким образом, можно будет использовать схемы 3+1 или 4+2, которые позволят иметь лишь в 1,3 раза больше физического пространства (для первой схемы), чем полезной емкости.

Но, понятное дело, для таких схем понадобится несколько больше хостов, чем, например, два.

Deduplication (дедупликация блоков)

Дедупликация блоков будет работать на уровне дисковой группы. Коэффициент дедупликации зависит от характера и разнообразия данных виртуальных машин, но при тестах он доходил до 8x.

Compression (сжатие данных)

Здесь каждый vmdk будет хранить только оригинальные дисковые блоки:

Ожидается, что для каждого 4KB блока в среднем удастся сэкономить 2KB.

Сделать запрос на бета-версию VMware Virtual SAN можно по этой ссылке.

На блоге vSphere появилась отличная статья о сервисах семейства vCenter Server Watchdog, которые обеспечивают мониторинг состояния различных компонентов vCenter, а также их восстановление в случае сбоев. Более подробно о них также можно прочитать в VMware vCenter Server 6.0 Availability Guide.

Итак, сервисы Watchdog бывают двух типов:

• PID Watchdog - мониторит процессы, запущенные на vCenter Server.
• API Watchdog - использует vSphere API для мониторинга функциональности vCenter Server.

Сервисы Watchdog пытаются рестартовать службы vCenter в случае их сбоя, а если это не помогает, то механизм VMware перезагружает виртуальную машину с сервером vCenter на другом хосте ESXi.

PID Watchdog

Эти службы инициализируются во время инициализации самого vCenter. Они мониторят только службы, которые активно работают, и если вы вручную остановили службу vCenter, поднимать он ее не будет. Службы PID Watchdog, контролируют только лишь наличие запущенных процессов, но не гарантируют, что они будут обслуживать запросы (например, vSphere Web Client будет обрабатывать подключения) - этим занимается API Watchdog.

Вот какие сервисы PID Watchdog бывают:

• vmware-watchdog - этот watchdog обнаруживает сбои и перезапускает все не-Java службы на сервере vCenter Server Appliance (VCSA).
• Java Service Wrapper - этот watchdog обрабатывает сбои всех Java-служб на VCSA и в ОС Windows.
• Likewise Service Manager - данный watchdog отвечает за обработку отказов всех не-Java служб сервисов platform services.
• Windows Service Control Manager - отвечает за обработку отказов всех не-Java служб на Windows.

vmware-watchdog

Это шелл-скрипт (/usr/bin/watchdog), который располагается на виртуальном модуле VCSA. Давайте посмотрим на его запущенные процессы:

mgmt01vc01.sddc.local:~ # ps -ef | grep vmware-watchdog

root      5767     1  0 16:20 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s rhttpproxy -u 30 -q 5 /usr/sbin/rhttpproxy -r /etc/vmware-rhttpproxy/config.xml -d /etc/vmware-rhttpproxy/endpoints.conf.d -f /etc/vmware-rhttpproxy/endpo
root      7930     1  0 16:21 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vws -u 30 -q 5 /usr/lib/vmware-vws/bin/vws.sh
root      8109     1  0 16:21 ?        00:00:11 /bin/sh /usr/bin/vmware-watchdog -s syslog -u 30 -q 5 -b /var/run/rsyslogd.pid /sbin/rsyslogd -c 5 -f /etc/vmware-rsyslog.conf
root      8266     1  0 16:21 ?        00:00:11 /bin/sh /usr/bin/vmware-watchdog -b /storage/db/vpostgres/postmaster.pid -u 300 -q 2 -s vmware-vpostgres su -s /bin/bash vpostgres -c 'LD_LIBRARY_PATH=/opt/vmware/vpostgres/curre
root      9422     1  0 16:21 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -a -s vpxd -u 3600 -q 2 /usr/sbin/vpxd
root     13113     1  0 16:22 ?        00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vsan-health -u 600 -q 10 su vsan-health -c '/opt/vmware/bin/vmware-vsan-health /usr/lib/vmware-vpx/vsan-health/VsanHealthServer.py -p 8006'
root     28775 19850  0 20:42 pts/0    00:00:00 grep vmware-watchdog

В понятном виде это можно представить так:

Давайте разберем эти параметры на примере наиболее важной службы VPXD:

-a
-s vpxd
-u 3600
-q 2

Это означает, что:

vpxd (-s vpxd) запущен (started), для него работает мониторинг, и он будет перезапущен максимум дважды в случае сбоя (-q 2). Если это не удастся в третий раз при минимальном аптайме 1 час (-u 3600 - число секунд), виртуальная машина будет перезагружена (-a).

Полный список параметров представлен ниже:

-d = DAEMONIZE
-n = QUIET
-b = BG_PROC-s = START
-k = STOP
-r = QUERY
-a = REBOOT_FLAG
-u = MIN_UPTIME
-q = MAX_QUICK_FAILURES
-t = MAX_TOTAL_FAILURES
-i = IMMORTAL
-c = CLEANUP_CMD
-f = EXIT_CLEANUP_CMD

Java Service Wrapper

Он основан на Tanuki Java Service Wrapper и нужен, чтобы обнаруживать сбои в Java-службах vCenter (как обычного, так и виртуального модуля vCSA). Вот какие службы мониторятся:

mgmt01vc01.sddc.local:~ # ps -ef | grep tanuki

cm        6331  6324  0 16:20 ?        00:00:37 /usr/java/jre-vmware/bin/vmware-cm -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=cm-log4j.properties -Dxml.config=ht
root      6876  6869  0 16:20 ?        00:00:50 /usr/java/jre-vmware/bin/vmware-cis-license -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=TRUE -XX:+ForceTimeHighRe
root      7267  7258  1 16:21 ?        00:03:45 /usr/java/jre-vmware/bin/vmware-sca -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lo
root      7634  7627  0 16:21 ?        00:00:29 /usr/java/jre-vmware/bin/vmware-syslog-health -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -DlogDir=/var/log/vmware/syslog -Dlog4j.config
1002      7843  7836  0 16:21 ?        00:01:08 /usr/java/jre-vmware/bin/vmware-vapi-endpoint -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=file:/etc/vmware-vapi//e
root      8453  8433  1 16:21 ?        00:02:55 /usr/java/jre-vmware/bin/vmware-invsvc -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dvim.logdir=/var/log/vmware/invsvc -XX:+ForceTimeHighResolution -XX:+ParallelRefP
root     10410 10388  0 16:22 ?        00:00:54 /usr/java/jre-vmware/bin/vmware-sps -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dxml.config=../conf/sps-spring-config.xml -Dpbm.config=../conf/pbm-spring-config.xml
1007     11099 11088  0 16:22 ?        00:01:27 /usr/java/jre-vmware/bin/vmware-vpx-workflow -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -ea -Dlog4j.configuration=conf/workflow.log4j.p
root     23423 19850  0 20:41 pts/0    00:00:00 grep tanuki

Если Java-приложение или JVM (Java Virtual Machine) падает, то перезапускается JVM и приложение.

Likewise Service Manager

Это сторонние средства Likewise Open stack от компании BeyondTrust, которые мониторят доступность следующих служб, относящихся к Platform Services среды vCenter:

• VMware Directory Service (vmdir)
• VMware Authentication Framework (vmafd, который содержит хранилище сертификатов VMware Endpoint Certificate Store, VECS)
• VMware Certificate Authority (vmca)

Likewise Service Manager следит за этими сервисами и перезапускает их в случае сбоя или если они вываливаются.

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm list | grep vm
vmafd       running (standalone: 5505)
vmca        running (standalone: 5560)
vmdir        running (standalone: 5600)

Вместо параметра list можно также использовать start и stop, которые помогут в случае, если одна из этих служб начнет подглючивать. Вот полный список параметров Likewise Service Manager:

list          List all known services and their status
autostart       Start all services configured for autostart
start-only <service>    Start a service
start <service>            	Start a service and all dependencies
stop-only <service>    Stop a service
stop <service>             Stop a service and all running dependents
restart <service>          Restart a service and all running dependents
refresh <service>         Refresh service's configuration
proxy <service>           Act as a proxy process for a service
info <service>             Get information about a service
status <service>          Get the status of a service
gdb <service>              Attach gdb to the specified running service

А вот таким образом можно узнать детальную информацию об одном из сервисов:

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm info vmdir
Service: vmdir
Description: VMware Directory Service
Type: executable
Autostart: yes
Path: /usr/lib/vmware-vmdir/sbin/vmdird
Arguments: '/usr/lib/vmware-vmdir/sbin/vmdird' '-s' '-l' '0' '-f' '/usr/lib/vmware-vmdir/share/config/vmdirschema.ldif'
Environment:
Dependencies: lsass dcerpc vmafd

Помните также, что Likewise Service Manager отслеживает связи служб и гасит/поднимает связанные службы в случае необходимости.

API Watchdog

Этот сервис следит через vSphere API за доступностью самого важного сервиса vCenter - VPXD. В случае сбоя, этот сервис постарается 2 раза перезапустить VPXD, и если это не получится - он вызовет процедуру перезапуска виртуальной машины механизмом VMware HA.

Эти службы инициализируются только после первой загрузки после развертывания или обновления сервисов vCenter. Затем каждые 5 минут через vSphere API происходит аутентификация и опрос свойства rootFolder для корневой папки в окружении vCenter.

Далее работает следующий алгоритм обработки отказов:

• Первый отказ = Restart Service
• Второй отказ = Restart Service
• Третий отказ = Reboot Virtual Machine
• Сброс счетчика отказов происходит через 1 час (3600 секунд)

Перед рестартом сервиса VPXD, а также перед перезагрузкой виртуальной машины, служба API Watchdog генерирует лог, который можно исследовать для решения проблем:

• storage/core/*.tgz - на виртуальном модуле VCSA
• C:\ProgramData\VMware\vCenterServer\data\core\*.tgz - не сервере vCenter

Конфигурация сервиса API Watchdog (который также называется IIAD - Interservice Interrogation and Activation Daemon) хранится в JSON-формате в файле "iiad.json", который можно найти по адресу /etc/vmware/ на VCSA или C:\ProgramData\VMware\vCenterServer\cfg\iiad.json на Windows-сервер vCenter:

mgmt01vc01.sddc.local:/ # cat /etc/vmware/iiad.json
{
"requestTimeout": 20,
"hysteresisCount": 4,
"remediatedHysteresisCount": 6,
"rebootShellCmd": null,
"restartShellCmd": null,
"maxTotalFailures": 50,
"needShellOnWin": true,
"watchdogDisabled": false,
"vpxd.watchdogDisabled": false,
"createSupportBundle": true,
"automaticServiceRestart": true,
"automaticSystemReboot": false,
"maxSingleRestarts": 3,
"maxSingleFailures": 2
}

Вот что это значит:

• requestTimeout – дефолтный таймаут для запросов по умолчанию.
• hysteresisCount – позволяет отказам постепенно "устаревать" - каждое такое значение счетчика при отказе, число отсчитываемых отказов будет уменьшено на один.
• rebootShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском ВМ.
• restartShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском сервиса.
• maxTotalFailures – необходимое число отказов по всем службам, которое должно случиться, чтобы произошел перезапуск виртуальной машины.
• needShellOnWin – определяет, нужно ли запускать сервис с параметром shell=True на Windows.
• watchdogDisabled – позволяет отключить API Watchdog.
• vpxd.watchdogDisabled – позволяет отключить API Watchdog для VPXD.
• createSupportBundle – нужно ли создавать support-бандл перед перезапуском сервиса или рестартом ВМ.
• automaticServiceRestart – нужно ли перезапускать сервис при обнаружении сбоя или просто записать это в лог.
• automaticSystemReboot – нужно ли перезапускать ВМ при обнаружении сбоя или просто записать в лог эту рекомендацию.
• maxSingleRestarts – верхний лимит попыток перезапуска упавшего сервиса.
• maxSingleFailures – число отказов, требуемой для срабатывания действия по перезапуску сервиса.

Также сервис IIAD перед перезапуском сервисов или виртуальной машины генерирует лог по адресу:

• /var/log/vmware/iiad/* - на виртуальном модуле VCSA
• %VMWARE_LOG_DIR%/iiad/* - в ОС Windows

Вот такой небольшой deep dive в службы доступности сервисов vCenter:)

Многие из вас знают утилиту esxtop (о которой мы часто пишем), позволяющей осуществлять мониторинг производительности сервера VMware ESXi в различных аспектах - процессорные ресурсы, хранилища и сети. Многие администраторы пользуются ей как раз для того, чтобы решать проблемы производительности.

Но оказывается, что использование esxtop само по себе может тормозить работу сервера VMware ESXi!

Это может произойти в ситуации, если у вас к ESXi смонтировано довольно много логических томов LUN, на обнаружение которых требуется более 5 секунд. Дело в том, что esxtop каждые 5 секунд повторно инициализирует объекты, с которых собирает метрики производительности. В случае с инициализацией LUN, которая занимает длительное время, запросы на инициализацию томов будут складываться в очередь. А как следствие (при большом числе томов) это будет приводить к возрастанию нагрузки на CPU и торможению - как вывода esxtop, так и к замедлению работы сервера в целом.

Выход здесь простой - надо использовать esxtop с параметром -l:

# esxtop -l

В этом случае данная утилита ограничит сбор метрик производительности только теми объектами, которые были обнаружены при первом сканировании. Соответственно, так лучше всего ее и использовать, если у вас к серверу VMware ESXi прицеплено много хранилищ.

На днях компания VMware выпустила полезный документ о лучших практиках по использованию "растянутых" кластеров на базе решения для создания отказоустойчивых хранилищ - "VMware Virtual SAN Stretched Cluster Performance and Best Practices".

Напомним также, что не так давно мы писали про конфигурацию VMware HA Stretched Cluster вместе с отказоустойчивыми хранилищами Virtual SAN.

Как и другие документы этой серии, этот whitepaper богат различными графиками и диаграммами, касающимися производительности решения. Например, вот производительность обычного кластера VMware Virtual SAN 6.1 и растянутого с задержками (latency) в 1 мс и 5 мс:

Основные моменты, раскрываемые в документе:

• Развертывание и настройка Virtual SAN Stretched Cluster
• Производительность растянутого кластера в сравнении с обычным
• Производительность кластера при различных отказах (хост, сайт целиком)
• Лучшие практики использования растянутых кластеров

Некоторое время назад вышло обновление VMware vSphere 6.0 Update 1, после чего пользователи Onyx под Web Client заметили, что он перестал работать. Напомним, что Onyx предназначен для записи действий пользователя в клиенте vSphere, после чего они записываются в виде сценариев PowerShell.

Теперь в обновленном Onyx для VMware vSphere Web Client, который можно скачать с сайта VMware Labs, новая версия vSphere 6.0 U1 полностью поддерживается.

Причина плохого поведения Onyx проста - так как этот продукт теперь полностью завязан на VMware vCenter, то теперь любое значимое изменение оного требует отдельного апдейта.

Мы уже не раз писали про VMware ESXi Embedded Host Client, который возвращает полноценный веб-клиент для сервера VMware ESXi с возможностями управления хостом и виртуальными машинами, а также средствами мониторинга производительности.

Совсем недавно на сайте проекта VMware Labs была опубликована третья версия этого полезнейшего средства - VMware ESXi Embedded Host Client Fling v3.

Теперь для этого продукте есть offline bundle, который можно накатывать с помощью VMware Update Manager, как на VMware vSphere 5.x, так и на VMware vSphere 6.x.

Одна из долгожданных фичей этого релиза - возможность просматривать и редактировать разделы дисков ESXi:

Если у вас есть это средство второй версии, то обновиться на третью можно с помощью следующей команды:

[root@mini:~] esxcli software vib update -v /esxui-signed.vib
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: VMware_bootbank_esx-ui_0.0.2-0.1.3172496
VIBs Removed: VMware_bootbank_esx-ui_0.0.2-0.1.3015331
VIBs Skipped:

Новые возможности VMware ESXi Embedded Host Client Fling v3:

Виртуальные машины

• Поддержка ответа на вопрос интерфейса (Answer question)
• Поддержка виртуального железа (Virtual Hardware) на самую последнюю версию, поддерживаемую хостом ESXi
• Горячее редактирование настроек ВМ
• Настройка колонок в конфигурации (показать/спрятать/ширина), которая сохраняется при рефреше страницы
• Настройка приоритета VM startup/shutdown

Хост ESXi

• Изменение политики электропитания (power management policy) и расширенные ее настройки
• Генерация запроса на подпись IP/FQDN-сертификатом и импорт сертификата
• Добавление хоста к контроллеру домена

Хранилища

• Редактор разделов диска хоста
• Рескан для обнаружения новых LUN и изменений в старых
• Обнаружение новых томов VMFS
• Очистка таблицы разделов на диске
• Диаграмма разбиения разделов диска
• Возможность увеличения хранилища для диска, у которого уже есть таблица разделов

Графики производительности

• Возможность изменять цвета диаграмм (дефолтная схема и высококонтрастная)
• Добавлены графики Network и Disk в разделе производительности
• Улучшенное быстродействие интерфейса
• Улучшенная производительность на планшетах
• Возможность спрятать верхнюю легенду на диаграмме
• Возможность спрятать виджет для расчистки места

Основное

• In-app update tool: возможность обновлять самого себя, просто подставив обновленный VIB-пакет
• Запоминается выбранная вкладка на планшете при навигации
• Более плавный скроллинг на планшетах
• Возможность спрятать интерфейс навигатора, оставив быстрые кнопки Host, Host Manage, Host Monitor, VMs, Storage и Networking
• Кнопка закрытия в менюшках
• Переподключение к консоли при потере соединения к ВМ или при откатывании к снапшоту
• Множественные багофиксы

Скачать VMware ESXi Embedded Host Client Fling v3 можно по этой ссылке.

Интересная возможность есть в VMware vSphere 6, которая может оказаться полезной для администраторов датацентров, которые имеют подчиненность главному ЦОД, который задает стандарты администрирования виртуальной инфраструктуры. Возьмем, например, РЖД - у них есть главный вычислительный центр (ГВЦ) и сеть информационно-вычислительных центров (ИВЦ) по всей стране, в которых, как и в ГВЦ, есть свои виртуальные инфраструктуры на платформе VMware vSphere.

Так вот, функция VMware vSphere Content Library позволяет подписать ИВЦ на обновления ГВЦ (который будет издатель/publisher), где можно создать шаблон виртуальной машины, а на уровне ИВЦ (подписчик/subscriber) администраторы этот шаблон ВМ увидят и установят. Очень удобно.

Для этого в центральном датацентре нужно перейти в раздел Content Libraries в vSphere Web Client:

Там нажимаем иконку создания нового объекта и добавляем новую библиотеку (Library):

Далее возьмем виртуальную машину, которую мы хотим превратить в шаблон (VM Template) и выберем из ее контекстного меню пункт Clone -> Clone to Template in Library:

Переходим на вкладку Related Objects и убеждаемся, что шаблон виртуальной машины добавлен в библиотеку:

Теперь, чтобы опубликовать библиотеку (Publish), нужно пойти на вкладку Manage, нажать Edit и поставить галку Publish this library externally (можно задать параметры доступа в разделе Authentication):

Уже в региональном датацентре нужно создать новую библиотеку:

И выбрать пункт Subscribed content library, указав URL центральной библиотеки паблишера:

После этого мы увидим в ней шаблон виртуальной машины, который мы создали в центральном датацентре:

Ну и из этого шаблона мы можем развернуть новую виртуальную машину в нашем региональном ЦОД на базе стандартов центра:

Как вы наверное заметили, помимо вкладки Templates, есть еще и вкладка Other Types, то есть можно публиковать не только шаблоны, но и другие объекты. Наиболее полезно будет распространять таким способом ISO-образы для гостевых ОС, а также скрипты для автоматизации различного рода операций. Удобная штука, но мало кто об этом знает.

Больше 5 лет назад мы писали о технологии VMware Storage I/O Control (SIOC), которая позволяет приоритизировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены. С тех пор многие администраторы применяют SIOC в производственной среде, но не все из них понимают, как именно это работает.

На эту тему компания VMware написала два интересных поста (1 и 2), которые на практических примерах объясняют, как работает SIOC. Итак, например, у нас есть вот такая картинка:

В данном случае мы имеем хранилище, отдающее 8000 операций ввода-вывода в секунду (IOPS), к которому подключены 2 сервера ESXi, на каждом из которых размещено 2 виртуальных машины. Для каждой машины заданы параметры L,S и R, обозначающие Limit, Share и Reservation, соответственно.

Напомним, что:

• Reservation - это минимально гарантированная производительность канала в операциях ввода-вывода (IOPS). Она выделяется машине безусловно (резервируется для данной машины).
• Shares - доля машины в общей полосе всех хостов ESXi.
• Limit - верхний предел в IOPS, которые машина может потреблять.

А теперь давайте посмотрим, как будет распределяться пропускная способность канала к хранилищу. Во-первых, посчитаем, как распределены Shares между машинами:

Общий пул Shares = 1000+2500+500+1000 = 5000

Значит каждая машина может рассчитывать на такой процент канала:

VM1 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS
VM2 = 2500/5000 = 50% = 0,5 * 8000 = 4000 IOPS
VM3 = 500/5000 = 10% = 0,1 * 8000 = 800 IOPS
VM4 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS

Если смотреть с точки зрения хостов, то между ними канал будет поделен следующим образом:

ESX1 = 3500/5000 = 70%
ESX2 = 1500/5000 = 30%

А теперь обратимся к картинке. Допустим у нас машина VM1 простаивает и потребляет только 10 IOPS. В отличие от планировщика, который управляет памятью и ее Shares, планировщик хранилищ (он называется mClock) работает по другому - неиспользуемые иопсы он пускает в дело, несмотря на Reservation у это виртуальной машины. Ведь он в любой момент может выправить ситуацию.

Поэтому у первой машины остаются 1590 IOPS, которые можно отдать другим машинам. В первую очередь, конечно же, они будут распределены на этом хосте ESXi. Смотрим на машину VM2, но у нее есть LIMIT в 5000 IOPS, а она уже получает 4000 IOPS, поэтому ей можно отдать только 1000 IOPS из 1590.

Следовательно, 590 IOPS уйдет на другой хост ESXi, которые там будут поделены в соответствии с Shares виртуальных машин на нем. Таким образом, распределение IOPS по машинам будет таким:

VM1 = 10 IOPS
VM2 = 4000+1000 = 5000 IOPS (так как установлен Limit)
VM3 = 800 + ((500/1500) * 590) = 997 IOPS
VM4 = 1600 + ((1000/1500) * 590) = 1993 IOPS

Все просто и прозрачно. Если машина VM1 начнет запрашивать больше канала, планировщик mClock начнет изменять ситуацию и приведет ее к значениям, описанным выше.

Компания VMware еще в августе выпустила полезный технический документ VMware Site Recovery Manager 6.1 Technical Overview, в котором описываются основные возможности средства для создания катастрофоустойчивых инфраструктур VMware SRM 6.1.

Основные сведения, которые можно почерпнуть из небольшого 22-страничного документа:

• варианты использования решения SRM
• основные топологии при построении архитектуры (active/active, active/passive и т.д.)
• развертывание и настройка продукта
• возможности механизма репликации
• сведения о настройке Protection Groups
• настройка и использование планов аварийного восстановления (Recovery Plans)
• рабочие процессы по тестированию аварийного восстановления, собственно аварийному восстановлению (Failover), а также возврату рабочей инфраструктуры с резервной на основную (Failback)

Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.

В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:

Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.

Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:

Смотрим, что получится и нажимаем Ok:

Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:

После выхода новой версии платформы VMware vSphere 6 перед многими администраторами встал вопрос об обновлении различных компонентов виртуальной инфраструктуры. На крупных предприятиях, как правило, используется не только платформа VMware ESXi и сервисы управления vCenter, но и различные корпоративные продукты, такие как VMware Horizon View для инфраструктуры виртуальных ПК или VMware vRealize Operations (vROPs) для мониторинга и решения проблем.

Вот в какой правильной последовательности нужно обновлять решения VMware (если у нескольких продуктов очередь одна - их можно обновлять в любой последовательности):

О проведении операций по обновлению компонентов решений VMware более подробно рассказано в статье KB 2109760. Там же приведены примеры сценариев обновления, если у вас есть определенный набор продуктов.

Кстати, помните, что после обновления на VMware vSphere 6.0 вы не сможете использовать продукт VMware Storage Appliance, который больше не поддерживается.

Если вы хотите узнать совместимость различных продуктов для виртуальной инфраструктуры, воспользуйтесь ресурсом VMware Product Interoperability Matrixes.

Этой статьёй я хочу открыть серию статей, целью каждой из которых будет описание одной из написанных мной функций PowerCLI или так называемых командлетов (cmdlets), предназначенных для решения задач в виртуальных инфраструктурах, которые невозможно полноценно осуществить с помощью только лишь встроенных функций PowerCLI. Все эти функции будут объединены в один модуль - Vi-Module. Как им пользоваться, можете почитать здесь.

На проходящей сейчас в Барселоне конференции VMworld Europe 2015 компания VMware раскрыла окончательные подробности технологии vSphere Integrated Containers (VIC), которая позволяет работать с инфраструктурой виртуализованных приложений Docker на базе существующей виртуальной инфраструктуры VMware vSphere.

Начнем обзор технологии VIC вот с этого видео, в котором показано, как поднять nginx на Photon OS:

Ключевым понятием инфраструктуры контейнеров является VCH - Virtual Container Host. На самом деле это не хост, а виртуальный объект, состоящий из ресурсов ресурсного пула (Resource Pool) VMware vSphere или кластера хостов ESXi целиком. Это позволяет создавать контейнеры в нескольких доменах в рамках одного или нескольких VCH (например, Production, Staging и Test).

Каждый VCH обслуживает собственный кэш образов, которые загружаются из публичного хаба Docker или из частных репозиториев. Файловые системы ВМ в контейнерах размещаются в виртуальных дисках VMDK, которые уже лежат на обычных VMFS-хранилищах.

Само управление инфраструктурой VIC происходит через плагин к vSphere Web Client. Также есть интерфейс командной строки и PowerCLI. Вот, например, процесс создания VCH:

Напомним, что каждый контейнер Docker размещается в отдельной виртуальной машине. Сделано это с целью лучшей управляемости и надежной изоляции приложений для безопасной и стабильной их работы. Но это было бы слишком расточительно с точки зрения потребления ресурсов, поэтому VMware использует подход VMFork - создание мгновенных клонов работающей виртуальной машины. Например, вот тут мы как раз писали о VIC-подходе.

Photon Controller использует механизм VMFork (сейчас эта технология называется VMware Instant Clone и доступна в vSphere 6) для создания мгновенных экземпляров виртуальных машин на базе Photon OS (за менее, чем 1 секунду) с нужным приложением по запросу от пользователя.

То есть, на базе Photon OS развертывается новая машина через VMFork, а в ней уже тянется контейнер из нужного репозитория.

Linux-контейнеры требуют Linx Kernel и работают как приложения в виртуальных машинах, которые могут выполнять только обозначенную контейнером задачу и не имеют никаких лишних обвесов и интерфейсов.

Также для контейнеров мапятся стандартные команды, которые доступны для виртуальных машин (Power Off / Power On). Например, если мы выключим виртуальный контейнер, это будет означать, что виртуальную машину с контейнером на борту мы удалили.

vSphere Integrated Containers на данный момент находятся в статусе Technology Preview, об их доступности будет сообщено дополнительно.

Возможно не все из вас в курсе, что есть такая полезная и бесплатная утилита как vSphere Configuration Backup, которая позволяет просто и через GUI настроить резервное копирование и восстановление конфигурации серверов VMware ESXi и баз данных SQL.

Возможности утилиты:

• Автоматическое резервное копирование конфигов серверов ESXi 4, 5 и 6 (протестировано vSphere 4.1, 5.0, 5.1, 5.5, 6).
• Резервное копирование любой локальной базы данных и ее конфигурации.
• Управление точками восстановления и удаление устаревших бэкапов (только для бэкапов ESXi).
• Для всего бэкапа конфига ESXi создается только один файл.
• В имени архива бэкапа указан номер билда ESXi.
• Сжимает резервные копии конфигурации ESXi для экономии места на диске.
• Не требует установки.
• Шифрует пароли.
• Конфигурируется из GUI через Configuration Manager.exe.

Как пользоваться vSphere Configuration Backup:

• Запускаем "Configuration manager.exe" для настройки параметров.
• Добавляем хосты ESXi (добавлять vCenter нельзя).
• Выбираем БД SQL Server для резервного копирования.
• Устанавливаем папку для бэкапов и политику хранения резервных копий (сколько хранить и когда удалять).
• Создаем таску планировщика для запуска "ESXi Configuration Backup.exe".

Скачать vSphere Configuration Backup можно по этой ссылке.

Для тех из вас, кто не читает ИТ-новости, спешим рассказать о том, что компания Dell (непубличная компания, между прочим) приобрела компанию EMC вместе со всеми ее активами, а значит и компанией VMware (у EMC 80% акций VMware). Сумма сделки составила 67 000 000 000 долларов (крупнейшая ИТ-сделка M&A за всю историю). В результате поглощения будет образована объединенная под брэндом Dell компания с годовым оборотом 90 миллиардов долларов. Поглощение планируется завершить до февраля 2017 года.

Акции EMC были оценены в $33,15 за штуку. Dell заплатит $24,05 за акцию наличными, а также и предоставит акционерам EMC специальный пакет акций, цена которых привязана к стоимости части принадлежащих EMC акций VMware. Майкл Делл уже заявил, что «Объединение EMC и Dell образует мощный генератор корпоративных решений». Открытое письмо Майкла можно почитать по этой ссылке.

Картинка в стиле "спасибо за игру":

Несмотря на то, что EMC еще может принять предложение одного из участников рынка (штраф от разрыва соглашения с Dell будет минимальным), вряд ли кто-то предложит более выгодные условия, чем Dell (да и мало у кого есть столько кэша, разве что у Cisco). Кстати, пишут, что Dell одолжила у Microsoft $2 млрд., чтобы финализировать сделку.

Интересно, останется ли EMC как брэнд или уйдет из жизни, как это произошло с Sun Microsystems? Открытым также остается вопрос о том, что будет с некоторыми продуктами и инициативами VMware, например, с публичным облаком vCloud Air, поскольку Dell очень тесно сотрудничает с Microsoft в плане облачных вычислений, в частности работает над Microsoft Azure Pack. Не зря же Microsoft одолжила деньги на эту покупку:)

Также возникают такие вопросы: что станет с инициативой EMC и Cisco под брэндом VCE? Что насчет недавно анонсированного партнерства Dell и Nutanix и конкурирующей с ним архитектуры VMware EVO:SDDC? 

На данный момент предполагается, что VMware останется независимой публичной компанией (по принципу laissez-faire). Стоимость её акций после анонса сделки почти не изменилась - акции торгуются на уровне $78,65 (плюс-минус 10% - это нормальная волатильность в таких случаях).

Кстати, на фоне анонса этой сделки компания VMware опубликовала предварительные финансовые итоги третьего квартала 2015 года. По сравнению с прошлым годом VMware увеличила выручку на 10%, которая теперь составила $1,672 млрд. долларов. На фоне падения интереса к технологиям виртуализации результат весьма и весьма неплохой.

Иногда администраторам хранилищ в VMware vSphere требуется передать логический том LUN или локальный диск сервера под другие цели (например, отдать не под виртуальные системы или передать в другой сегмент виртуальной инфраструктуры). В этом случае необходимо убедиться, что все данные на этом LUN удалены и не могут быть использованы во вред компании.

Раньше это приходилось выполнять путем загрузки из какого-нибудь Linux LiveCD, которому презентован данный том, и там удалять его данные и разделы. А в VMware vSphere 6 Update 1 появился более простой способ - теперь эта процедура доступна из графического интерфейса vSphere Web Client в разделе Manage->Storage Adapters:

Теперь просто выбираем нужный адаптер подсистемы хранения и нажимаем Erase для удаления логических томов устройства (будут удалены все логические тома данного устройства):

Теперь можно использовать этот локальный диск по другому назначению, например, отдать кластеру VSAN.

Ну и также отметим, что в следующей версии утилиты ESXi Embedded Host Client компания VMware сделает возможность не только удаления таблицы разделов, но и добавит средства их редактирования:

Компания «ИТ-ГРАД», первый VMware IaaS-провайдер на территории СНГ, открывает свое представительство в Алматы. Вслед за открытием Казахстанского офиса запланирован запуск облачного центра обработки данных, отвечающего международным стандартам надежности и требованиям законодательства Казахстана. Облачный дата-центр позволит разместить в облаке бизнес-приложения, воспользоваться облачным резервным копированием и другими услугами «ИТ-ГРАДа».

Ориентируясь на высокие требования заказчиков по обеспечению доступности хранимых данных, компания ИТ-ГРАД строит облачную инфраструктуру по принципу отсутствия единой точки отказа. При этом в качестве площадки для размещения выбираются только надежные дата-центры, категории не ниже Tier III в соответствии с требованиями Uptime Institute.

Услуги «ИТ-ГРАДа» пользуются высоким спросом в России и за ее пределами. В Казахстане будут представлены наиболее популярные облачные сервисы. На базе открывающейся облачной площадки заказчики смогут воспользоваться следующими услугами на территории Казахстана:

• Аренда виртуальной инфраструктуры (IaaS) – позволяет заказчику перенести собственные серверы в виртуальный дата-центр в облаке «ИТ-ГРАДа», тем самым снизив затраты на поддержку и обслуживание информационных систем.
• Резервная площадка (DRS) – позволяет организовать площадку для аварийного восстановления ИТ-инфраструктуры заказчика в облачной среде. В первую очередь решение предназначено для компаний с собственной виртуальной инфраструктурой, либо планирующих использовать технологии виртуализации VMware vSphere.
• Резервное копирование в облако (BaaS) — «ИТ-ГРАД» предлагает своим клиентам подключить свою инфраструктуру к облачному корпоративному решению для резервного копирования с возможностью восстановления данных в том числе в облако. Используются продукты и технологии компаний CommVault и Veeam.

Более подробно с услугами компании ИТ-ГРАД можно ознакомиться на этой странице.

Несколько лет назад мы писали про политики сложности паролей в VMware vSphere, которые определяют, какой пароль можно установить для пользователей ESXi. Аутентификация на ESXi реализуется с помощью подключаемых модулей аутентификации (Pluggable Authentication Modules, PAM), которые обладают различными возможностями, такими как интеграция с Active Directory, большая устойчивость к подбору пароля и дополнительные возможности (например, задание сложности пароля для различных классов символов).

Разберем сначала структуру политики сложности пароля:

retry=3 min=N0,N1,N2,N3,N4

• retry=3 - допустимое число попыток ввода пароля.
• N0 - минимальная длина пароля, который имеет только символы из класса 1 (это символы букв в нижнем регистре - например, abc).
• N1 - это минимальная длина пароля, который обязательно имеет символы из двух классов (классы 1,2 и 3 - это символы букв в нижнем и верхнем регистре, а также цифры - например, abcABC).
• N2 - пароли, имеющие в составе слова, должны быть длиной не менее 8 символов. Например, vmwareee.
• N3 - это минимальная длина пароля, который обязательно имеет символы из классов 1, 2 и 3 (это буквы в нижнем и верхнем регистрах, а также цифры - например, abcABC123).
• N4 - это минимальная длина пароля, который обязательно имеет символы из классов 1, 2, 3 и 4 (это буквы в нижнем и верхнем регистрах, а также цифры и спецсимволы - например, abcABC123!).

Напомним политики паролей, которые были в VMware ESXi 5.x:

ESXi 5: retry=3 min=8,8,8,7,6

Это значит, что можно было:

• Задать пароль длиной в 8 символов из первого класса, например: thsmypwd
• Задать пароль длиной в 8 символов из первого и второго класса, например: thsmypwD
• Задать пароль из 8 символов, содержащем слово, например: vmwareee
• Задать пароль длиной в 7 символов из первого, второго и третьего класса, например: VMware1
• Задать пароль длиной в 6 символов из первого, второго и третьего класса, например: Vare1!

В VMware ESXi 6 политика сложности пароля была еще усложнена и теперь является такой:

retry=3 min=disabled,disabled,disabled,7,7

То есть, теперь пароль обязательно должен содержать минимум 7 символов, среди которых обязательно есть символы по крайней мере трех из четырех классов.

Но самое интересно, что политики сложности пароля ESXi теперь можно редактировать не в PAM-файлах сервисной консоли, а в расширенных настройках хоста в разделе Security (картинка кликабельна):

То есть, просто меняете параметр Security.PasswordQualityControl и перезагружаете хост ESXi.

Для массового изменения политик сложностей пароля можно использовать следующий PowerCLI-скрипт:

$PasswordPolicy = "retry=3 min=8,8,8,7,6"
$VMHosts = Get-VMHost | Where { $_.ConnectionState -eq "Connected" }
foreach ($VMHost in $VMHosts)
{
$VMHosts | Get-AdvancedSetting -Name "Security.PasswordQualityControl" | Set-AdvancedSetting -Value $PasswordPolicy -Confirm:$false
}

Спустя весьма продолжительное время с момента релиза новой версии платформы vSphere 6.0, компания VMware выпустила обновленную версию статьи базы знаний KB 2131180, в которой приведена схема со всеми портами и соединениями, используемыми в виртуальной инфраструктуре.

Штука это очень полезная и прямо просится на стенку в виде плаката в помещение, где сидят администраторы VMware vSphere. На страницах с 3 по 9 находится таблица со всеми соединениями, где указаны номера портов, протокол, источник и целевой компонент, а также назначение соединения.

Всем очевидно, что люди, которые пишут о продуктах и технологиях вендоров ПО и железа, а также принимают активное участие в различных мероприятиях, создают большой вклад улучшение имиджа продукта и компании, увеличивают их популярность, а, как следствие, увеличивают и продажи.

Поэтому многие вендоры оборудования и программного обеспечения в сфере виртуализации запустили свои программы по поощрению специалистов, наиболее активно принимающих участие в публичных активностях (пишущих блоги, выступающих на конференциях, организующих юзер-группы и т.п.).

Давайте посмотрим, какие звания/награды вы можете получить, если, например, начнете вести свой блог соответствующей тематики:

• VMware vExpert

Это одна из первых программ VMware, которая была учреждена для стимулирования блоггеров и активных участников VMware User Group (VMUG). В 2009 я получил первого vExpert и с тех пор получал каждый год. Сначала пришла папочка из кожзама, потом обещали сумку, но она так и не доехала:) Потом они перестали вообще что-то высылать, а сама награда vExpert утратила былую ценность, так как награждать стали всех подряд. Да и как-то она теперь дается не по году, а по полугодиям, что весьма странно - кому это надо?

• Veeam Vanguard

Это награда от компании Veeam Software, выпускающей лучший продукт для резервного копирования и репликации виртуальных машин Veeam Backup and Replication, а также средство номер 1 для мониторинга и управления различными аспектами виртуальной среды Veeam One. Награда эта появилась только в этом году, но список награжденных уже включает в себя 34 профессионала, которые имеют большой опыт работы с продуктами и технологиям Veeam. И программа Veeam Vanguard для меня лично особенно приятна тем, что в этом году я еду в Лас-Вегас на международную конференцию VeeamOn 2015, где будут все самые значимые профессионалы в сфере виртуализации и защиты данных, а также будет множество интересных новостей и анонсов. Мы будем вести оттуда живую текстовую трансляцию!

• Microsoft MVP

Награде MVP (Most Valuable Professional) уже тысяча лет, наверняка многие из вас знают парочку MVP, с которыми пересекались на конференциях. За вклад в сообщество Microsoft ежегодно награждаются сотни специалистов по всему миру в различных сферах, таких как ASP.Net или SQL Server. По теме платформы виртуализации Hyper-V на данный момент 268 специалистов MVP (из России - 3 человека).

• Nutanix Technology Champion (NTC)

Эта награда от компании Nutanix, занимающейся разработкой программно-аппаратных комплексов для хранения данных. Первый раз она была анонсирована в прошлом году. Как раз сейчас и до 26 октября открыто номинирование на NTC, поэтому если вы что-то делаете по этой теме - можете попытаться получить звание NTC.

• EMC Elect

Это ежегодная награда от EMC за вклад в развитие как программных, так и аппаратных решений компании. Вот тут находится полный список награжденных по результатам прошлого года (из знакомых вам - Антон Жбанков). Номинация на 2016 год пока еще не открыта.

• Cisco Champions

Несмотря на то, что компании Cisco тоже сто лет в обед, программа поощрения технических специалистов Cisco Champions была анонсирована только в 2014 году. Вот тут рассказано о том, за что специалисты получают награду, а вот тут находится их список.

• Citrix Technology Professional (CTP)

Наряду с MVP от Microsoft, CTP от Citrix - одна из старейших наград. Вот здесь можно посмотреть текущий список награжденных. Номинация открыта прямо сейчас и до 30 октября, так что если вы популяризуете Citrix XenApp/XenServer/XenDesktop или другие решения Citrix - попытайте счастья с помощью этой формы.

На днях компания VMware объявила о доступности решения Horizon Mirage 5.5, предназначенного для управления образами корпоративных ПК предприятия в рамках инфраструктуры VMware Horizon, включающей в себя также решение для виртуализации настольных ПК VMware Horizon View.

Напомним, что решение VMware Mirage позволяет создать образ рабочей станции пользователя, разделив его на слои (система, приложения, а также данные и настройки пользователя), а потом централизованно управлять такими образами и деплоить их на конечные физические и виртуальные ПК (подробно мы писали об этом тут). О прошлой версии решения VMware Horizon Mirage 5.2 мы рассказывали в этой заметке.

В этом релизе Mirage компания VMware сделала упор на функциях управления образами с минимальным влиянием на рабочие процессы пользователей. Также стали доступны возможности по самостоятельному развертыванию устройств без необходимости доступа к Mirage Management Console. Теперь администраторы филиалов могут развернуть новый ПК со своего устройства через браузер.

Основные новые возможности VMware Horizon Mirage 5.5:

• Интерфейс самообслуживания для локальных администраторов филиалов для развертывания новых лэптопов и ПК. Делается это через встроенный браузер на основе WinPE.
• Администраторы могут определить базовый слой ОС и приложения только для загрузки (на уровне своего филиала), а запустить обновление вручную в часы наименьшей нагрузки.
• Администраторы могут определить ширину полосы пропускания в зависимости от времени суток и дня (рабочий/выходные). Это снижает трафик загрузок образов в пиковые часы.
• Обновление слоев ОС и приложений возможно через интерфейсы Mirage API и Mirage PowerCLI.
• Развертывание на устройства без ОС поддерживает стандарт POSReady 2009.

Улучшения продукта:

• Можно удалять слои Mirage, используя Mirage Web console, даже если слои назначены активным или архивным CVD (centralized virtual desktop).
• Возможность сохранения статической IP и DNS-конфигурации при миграции ОС, развертывании нового ПК или его восстановления.
• При валидации слоя Microsoft Office выводится информация о конфликтующих компонентах.
• Функции управления устройствами, на которых есть McAfee Data Loss Prevention Endpoint (DLP), включая операции миграции, развертывания и восстановления.
• Использование MongoDB для хранения системных данных и маленьких файлов.
• Файлы базы данных MongoDB могут управляться отдельно от томов Mirage.
• Если на диске, где находится MongoDB, осталось мало места - администратор оповещается об этом.

Улучшения Mirage Web Console:

• Через веб-консоль можно редактировать следующие настройки:
  • Просмотр и управление лицензиями
  • Импорт USMT
  • Настройки файлового портала
  • Возможность автосоздания CVD
  • Аутентификация шлюза
• Возможность "провалиться" при просмотре назначения CVD, которые являются частью коллекции или задачи.
• Управление серверами Mirage и Mirage Gateway.

Скачать новую версию VMware Horizon Mirage 5.5 можно по этой ссылке.

Мы уже писали о новой версии решения VMware Virtual SAN 6.1, предназначенной для создания отказоустойчивых хранилищ на платформе VMware vSphere. После того, как издания "hybrid" и "all-flash" были переименованы в "standard" и "advanced" соответственно, у пользователей появилось несколько вопросов о функциональности этих изданий.

Начнем с того, что в целом все осталось как было:

Итак, мы видим, что отличий у изданий Standard и Advanced теперь два:

• Для конфигураций только из SSD-дисков серверов можно использовать только издание Advanced.
• Для "растянутых" кластеров также можно использовать только издание Advanced. Но тут есть нюанс - растянутым кластером можно считать географически разнесенные площадки (на уровне двух разных зданий). Если у вас кластер на уровне стоек в двух серверных или на разных этажах - растянутым он не считается.

Также появилось издание VSAN for ROBO (remote or branch offices). Это издание позволяет использовать решение VSAN компаниям имеющую сеть небольших филиалов, где нет большого числа хостов ESXi. Для такой лицензии можно запустить не более 25 виртуальных машин в рамках филиала и одной ROBO-лицензии.

Здесь кластеры строятся на уровне каждого из филиалов, а witness-компонент (виртуальный модуль, следящий за состоянием кластера) располагается в инфраструктуре центрального офиса. Причем на каждый кластер VSAN нужно по отдельному witness'у. Этот самый witness позволяет построить кластер на базе всего двух узлов, а не трех, так как он следит за ситуацией split brain в кластере. Это позволяет удешевить решение для филиала, использовав для инфраструктуры из 25 машин всего 2 сервера. Более подробно о ROBO-сценарии написано вот тут.

А вот как выглядит настройка ROBO-издания Virtual SAN:

Ну и, само собой, ROBO-сценарии можно реализовывать по своему усмотрению на лицензиях Standard или Advanced.

На прошедшей конференции VMworld 2015 компания VMware анонсировала программно-аппаратную архитектуру VMware EVO SDDC, которая пришла на смену архитектуре EVO:RACK, которая, в свою очередь, была продолжателем подхода EVO:RAIL, о котором мы уже писали вот тут. SDDC - это концепция Software-Defined Data Center, то есть программно определяемый датацентр, где все физические ресурсы виртуализованы, абстрагированы от оборудования (то есть администратор оперирует логическими сущностями) и управляются из одной точки с помощью специализированного программного обеспечения.

Эта архитектура позволяет вендорам аппаратного обеспечения и OEM-партнерам VMware поставлять интегрированные законченные решения для создания виртуальной инфраструктуры в виде готовых к эксплуатации стоек с оборудованием и развернутым на нем программным обеспечением. На данный момент договоры уже подписаны с Dell, VCE и Quanta (они начнут поставки в первой половине 2016 года), другие вендоры также вскоре объявят о сотрудничестве с VMware.

Такой подход позволяет создать новую инфраструктуру или включить дополнительные ресурсы в уже существующую буквально за несколько часов. Ключевым компонентом такой инфраструктуры является средство управления EVO SDDC Manager. Инфраструктура под управлением EVO SDDC Manager является гиперконвергентной (hyper-converged infrastructure, HCI), то есть все ресурсы виртуализованы (серверы, хранилища и сети), находятся под управлением единого средства и управляются из одной точки.

С точки зрения аппаратного обеспечения, типовой базовый блок VMware EVO SDDC включает в себя 8 серверов, пару коммутаторов 10 Gbit Ethernet, один коммутатор управления и пару 40 Gbit spine-коммутаторов с 32 портами для связи между стойками. Все это уже полностью собрано, скоммутировано и настроено.

Полностью настроенный блок EVO SDDC из 24 серверов в максимальной конфигурации позволяет запустить в облаке предприятия или сервис-провайдера IaaS более 1000 виртуальных серверов или более 2000 виртуальных ПК:

А где же система хранения? - спросит вы. А ее тут нет, все хранение виртуальных машин осуществляется на базе локальных дисков серверов, объединенных в единое пространство хранения с помощью решения VMware Virtual SAN.

С точки зрения программного обеспечения, EVO SDDC включает в себя следующие компоненты:

• VMware vSphere
• VMware NSX
• VMware Virtual SAN
• VMware vRealize Operations
• VMware vRealize Log Insight
• VMware vRealize Automation (опционально)
• VMware Horizon Suite (если стойка используется для виртуальных ПК)

Все эти вещи позволяют не только исполнять виртуальные машины, но и обеспечить отказоустойчивость хранилищ, виртуализацию сетей, а также предоставить средства мониторинга, автоматизации и решения проблем.

Вот так выглядит рабочий процесс путешествия стойки от партнера к клиенту и ее ввод в эксплуатацию:

Более подробно об архитектуре VMware EVO SDDC можно узнать из этого документа.

Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.

Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.

Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.

К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.

Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:

Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.

Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.

Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.

Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!

Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:

В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).

Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.

Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:

Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:

Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:

Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.

Недавно мы писали том, что компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 версии 2.8. Эта версия прошла инспекционный контроль в ФСТЭК России и доступна для загрузки и покупки. В обновленную версию vGate R2 добавлены новые механизмы защиты и расширенные функции по администрированию системы. Сегодня мы расскажем о том, как в vGate R2 выглядит рабочий процесс для пользователей в защищенной среде.